Plasma Chamber General View
Plasma Chamber is both a custom Plasma structure derived from inspired by Plasma Cashflow and Plasma Prime, and a specific suite of tools added to that Plasma infrastructure.
The general model
A user’s Ethereum address deposits fungible tokens on an Ethereum smart contract. As a consequence of this deposit, the contract sends an equivalent amount of pseudo-fungible coins to the child chain.
These child-chain pseudo-coins are « images » of the original coins locked on the smart contract. So Plasma operations and transactions will happen using pseudo-coins, until the final settlement where the resulting amount of pseudo-coins is sent to the rootchain, and allows, on the rootchain, for the widhdrawal of the resulting amount in real coins by the user.
(A bit like in casino, where you deposit real money at the beginning and withdraw real money at the end, like rootchain coins, but meanwhile you transact with plastic tokens, like child chain pseudo-coins.)
When being sent to the child chain, these tokens are sent as 1 single UTXO (Unspent Transaction Output), that has a unique ID.
But this single UTXO can be spent in divided amounts, so that the pseudo-coins are also fungible in practice, like the original coins they represent. Still, all chunks are referring to the same UTXO and to the same ID.
The single UTXO acts as a dynamic « registry » of the available pseudo-coins, that keeps track of what has been spent of it and what remains to be spent. The UTXO can also be exited to the root chain, which means that the root chain smart contract is informed of the remaining pseudo-coins available in the UTXO, and unlocks the real coins on the rootchain for the user to withdraw them, while the pseudo-coins can not be spent anymore on the child chain.
For every transaction happening on the child chain, including exit transactions, all users can detect invalid actions (double spend, block withdrawal, invalid ownership), thanks to a piece of software they trigger manually that checks what happens to their own coins and UTXO. So one by one, all UTXOs are watched by their respective owners, so that, in total, the whole network is watched, with little work for each player.
The blocks on the child chain include each coin’s ownership history : how the pseudo-coins and pseudo-coins fractions were spent, meaning how each user’s UTXO was spent, to what user each fraction went, and what belongs to what user.
To enforce honest behaviour and safe actions, users can challenge the operators : when they detect invalid actions and submit the corresponding proof of invalidity (for instance, showing that a UTXO has already been spent and is now attempting to be spent again), the operations chain gets stopped, resulting in non-finalization of malicious transfers or ownerships, and allowing for mass-exit of all users to a parent chain if necessary. It also results in the loss of bonded tokens for the malicious actor, in favor of the detecting actor, and oppositely, if the detecting actor was the malicious one, he loses his own bonded tokens.
In order to allow end users to check validity and to produce such challenges, as it requires them to be online and to trigger a certain software that does the checking, transactions are followed by a certain time in days before being validated: users don’t have to watch 24/7, but it is expected that they will be online once in a while, and consequently able to use this delay time to challenge the latest pending transactions involving their coins and UTXO.
The challenges game and its ability to block operations when necessary also allows to rely on a single operator’s actions (Proof of Authority), with the assurance that funds will be safe even if the operator appears unreliable. One operator instead of many accelerates operations, and allows for higher throughput.
Acceleration and higher throughput with maintained safety is precisely the goal of Plasma.
After the challenges delay, when a user wants to terminate his operations on the Plasma chain, and send back his pseudo-coins to the root chain in order to unlock and withdraw his real coins there, an exit transaction is needed, sent by the child chain to the root chain. This exit transaction must be confirmed by its own existence proof, that consists of a Merkle root hash of a Merkle tree, the Merkle proofs to be able to calculate and check the validity of the Merkle hash (the necessary leaves - hashes), and the block height.
The Merkle tree’s leaves are users transactions’ hashes, including the requested exit’s transaction, proving that the transaction was requested, not succesfully challenged, and successfully included in the block.
The Merkle root is submitted to the root chain, for instance Ethereum, enforcing the security of the whole thanks to the rootchain’s high security, while sticking to a minimum piece of submitted data: this root hash is 32 bytes, and can be the resulting hash for thousands of transactions, which means a drastically reduced gas cost compared to submitting the whole transactions data to the root chain.
Plasma Chamber features
Besides fulfilling the wallet function on the Plasma chain, meaning a transactions address and a safe storage for coins, Plasma Chamber’s Wallet integrates an inspector of the UTXO history data : the inspector is triggered everytime the user’s UTXO is involved in an incoming or outcoming transaction, and automatically checks the Merkle proofs submitted by the child chain, and events happening on the root chain contract. The wallet’s Guard feature will also detect any invalid exit involving an UTXO owned by the wallet.
This all-in-one architecture, integrating a reliable inspector to the wallet, is an exclusive Plasma Chamber design.
And as each user is responsible for his own UTXO, and each user’s UTXO is secured by its own wallet’s inspector, the whole consequent Plasma chain is therefore secure, and finally enforced by the root hash submitted to the root chain for every Plasma block confirmed.
The Chamber Wallet SDK allows applications developers to integrate wallets leveraging Plasma Chamber features, when creating their own Plasma Dapps (plapps) : generation and handling of transactions, whether they are transfer transactions or more complex custom transactions that necessitate transaction verification and state verification, as well as history verification, guard feature, and synchronization of root chain and child chain data.
In other words, Plasma Chamber Wallet SDK is the de facto perfect framework for developing plapps of any kind.
And of course, these plapps will benefit Plasma Chamber’s custom Security guarantees, inspired by the original Plasma Cash protocol and using its original robust security model, while extending it to support fungibility of coins, thanks to the range feature that allows dividing an UTXO in many subsets or segments.
As the UTXO can be fragmented into many segments to allow fungibility, a defragmentation feature is also provided by Plasma Chamber to reduce the number of separate fragments, by triggering intra-chain inter-users (inter-UTXOs) balancing of small amounts.
Which is why it involves atomic swap, and a secure exit game based on the Force inclusion function, that makes the operator the broker for the atomic swap request between two users : this way, the two users don’t need anymore to be online at the same time to process the atomic swap.
The protocol incentivizes the operator to act honestly and to maintain the chain defragmented, so that the funds’ security is kept at the highest level.
A simple exit game for transfer transactions prevents malicious exits, rearrangement and withholding attacks, and guarantees each user’s funds’ security, while for custom transactions that involve more complex operations than coins transfer, such as swaps, multisig or escrow functions based on UTXO contracts, Plasma Chamber provides a specific exit game to secure these situations.
And to reduce the transaction history that each user has to check, as it is expected to reach a fairly heavy weight with time, Plasma Chamber makes use of the Checkpoints protocol, inherited from the Plasma XT implementation : at regular intervals in time, the state of a coin is considered finalized, after being attested by the operator, and open to challenges for a certain time. This way, only the most recent set of operations has to be included in the coin’s history, maintaining the total proof size to a decently small constant.
On top of this, as some users will want to circumvent the few days delay that follows an exit transaction request before it gets validated, in order to retrieve their funds quickly, Plasma Chamber provides the Fast finality function, available to limited third party service providers that hold wallets and control values transfers for their clients.
The service provider buys a Fast Finality Token from the chain operator, in exchange of the operator processing the transaction quickly. The Fast Finality bandwidth is sold by a specific merchant wallet, and also allows service providers to challenge the operator in case he doesn’t fulfill his part of the deal.
The Merchant wallet is based on a Proof of Stake protocol (PoS), meaning that it necessitates bonded tokens that will be slashed in case of a dishonest behaviour, to secure the use of the Fast finality function.
Developers also have the choice to implement longer exit periods, while still allowing end-users to retrieve their funds immediately thanks to simple fast withdrawals : Alice triggers a regular (slow) exit transaction, creating a non-fungible ERC721 token representing the right to receive the value of this exit. She then immediately sells this token to Bob, for the same value minus a payment fee for Bob.
This way, Alice gets her funds now from Bob from the token’s sale, and Bob then uses the token to get refunded when the slow exit transaction is finalized, while having been paid on the way. This system also allows for the creation of a marketplace for such operations between users.
In the near future, Plasma Chamber’s usability will be improved through added functionalities such as escrow with trusted third party, escrow SDK, transaction format verifier, cloud keystore with email and passphrase access, integration of DAI and of Japanese Yen stablecoin LCJPY, instant deposit from mobile banking apps, more flexible fee models, and appropriate custom exit games for every specific operation.